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1. Introduction 

In developing IndEA, the Working Group was acutely aware that for successful adoption, 
guidance would be needed to help state governments, ministries and departments in the 
governments at various levels to adopt a structured approach when making use of IndEA in 
developing their enterprise architectures. Therefore, this guide expected to fill a clear gap in current 
capability and drive the adoption of IndEA in an effective manner. 

a. Scope & Purpose 

This guide covers the following: 

• Briefly explains government enterprise architecture and its relevance to India's e-governance 
initiatives; 

• Summarises pioneering enterprise architecture initiatives in the government sector, with a view 
to set the context and provide insights into what has been done and where to look for practical 
examples; 

• Summarises IndEA, and elaborates the way to use the Reference Models by government entities 
to develop their own architectures; and 

• Provides further guidance through reference to other relevant material and content based on 
first hand field-tested experience. 

Note that this document is not a step-by-step methodology to develop enterprise architecture. 

b. Related Documents 

This document is to be read in conjunction with the following: 

• India Enterprise Architecture Framework. 

• ePragati Vision Document 1 . 

• The Open Group Architecture Framework (TOGAF) Management Overview 2 . 

• TOGAF Leader's Guide in Establishing and Evolving an EA Capability 3 . 

A complete list of references is provided in Section 8. 

c. Intended Audience 

This guide is primarily intended for the following groups: 

• All central government ministries, state governments and local governments especially those 
that do not currently have an enterprise architecture initiative or are just in the early stages of 
their enterprise architecture development; 

• Senior government officials who have been tasked to oversee and guide enterprise architecture 
initiatives to augment their understanding and promote active commitment; and 

• Government Leaders, Chief Architects, Analysts and Designers seeking better, quicker and easier 
approaches to respond to the needs of their internal and external customers. 


1 http://e-pragati.ap.gov.in/documents/AP%20Enterprise%20Architecture.pdf 

2 http://www.togaf.info/togafSlides91/TOGAF-V91-Ml-Management-Overview.pdf 

3 https://www2.opengroup.org/ogsvs/catalog/G168 


6 


NeST 










India Enterprise Architecture Framework 

Version 1.2 October 2017 

The following groups will also find this useful: 

• Policy Analysts, Line-of-Business Managers concerned with maximizing business value of IT and 
business competitiveness; 

• Consultants and practitioners desirous of new solutions and technologies to improve the 
productivity of their government clients; 

• Business management, public policy and IS management educators interested in imparting 
knowledge about this vital discipline; and 

• Electronic government professionals involved with organisational technology strategic planning, 
technology procurement, management of technology projects, consulting and advising on 
technology issues and management of total cost of ownership. 
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2. Government Enterprise Architecture in India 

Though not widespread, there have been some efforts towards adoption of enterprise 
architecture within the government. As the experience derived from these initiatives have played a 
critical role in enriching the development of IndEA, the following three sub-sections summarise the 
cases of enterprise architecture in the Ministry of Panchayati Raj, Ministry of Drinking Water and 
Sanitation and Andhra Pradesh State Government. Collectively, they represent a vertical line of 
business (Ministry of Drinking Water and Sanitation), horizontal line of business (Ministry of 
Panchayati Raj) and a state government (Government of Andhra Pradesh). 

PANCHAYAT ENTERPRISE ARCHITECTURE FRAMEWORK (PEAF) [2011] 

The 73 rd Constitutional Amendment Act of India, 1992 was a landmark event that enabled 
decentralised and participative governance through Panchayats in the rural areas covering three- 
quarters of India's population. Panchayats function at the village, intermediate (block) and district 
levels. There are approximately 239,819 Gram Panchayats at the village level, 6,321 Intermediate 
Panchayats at Block level and 592 Zilla Panchayats at the district level. All these three tiers are 
represented by approximately 2.8 million elected representatives and 1 million functionaries. 

The three-tier institutional structure of Panchayats offer India's rural villagers an opportunity 
to participate in the development of local area through their involvement in preparation, execution, 
monitoring of development plans and programmes. They also provide a platform to the citizens to 
directly interact with their elected representatives to ensure that their interests are effectively 
served and the public funds are properly spent. Panchayats, are symbols of decentralisation, 
governance and grassroots democracy. 

The key identified objectives of e-Governance that formed the pillars of the PEAF in 
Panchayats included: 

• Providing aid to decision making to the Panchayats; 

• Providing the means to improve the internal efficiency and management of Panchayats; 

• Better and convergent delivery of services to citizens; and 

• Encouraging transparency, disclosure to citizens and open to social audit; 

Following are the areas of operations of Panchayats, which formed a key input to the business 
architecture. 
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Agriculture, ind. extension 

Drinking water 

Cultural activities 1 

Land improvement, land reforms, 
consolidation, soil conservation 

Fuel and fodder 

Markets and Fairs 

Minor irrigation, 
water management, 
watershed development 

Roads, culverts, bridges, 

ferries, waterways, other means of 

communication 

Health and sanitation 
hospitals, primary health centres, 
dispensaries 

Animal husbandry, 
dairying and poultry 

Rural electrification, 
distribution of electricity 

Family welfare 

Fisheries 

Non-conventional energy 

Women & Child Development 

Social forestry, 
farm forestry 

Poverty alleviation programme 

Social Welfare, welfare if handicapped 
and mentally retarded 

Minor forest produce 

Education, including primary 
and secondary schools 

Welfare of the weaker sections, 
in particular of SCs and STs 

Small scale industries, 
food processing industries 

Technical training, 
vocational education 

Public Distribution System 

Khadi, village and 
cottage industries 

Adult and non-formal education 

Maintenance of community assets 

Rural housing 

Libraries 



Figure 2-1: Business Areas of Panchayats in India 


These business areas were then organised into business categories, core and enabling 
business functions to form the PEAF Business Function Map (see Figure 2-2), a key output of the 
business architecture. The business function map formed the basis for the rest of the architecture 
analysis and development. The business functions were decomposed to identify the business (G2C, 
G2B) services under the purview of Panchayats and analysed for efficiency, redundancies, delivery 
channels, stakeholders and payment mechanisms. The underlying business processes realising these 
services were analysed and improvements identified. The business functions and the services were 
mapped to the roles (covering the three layers of Panchayats) to identify gaps and overlaps. This also 
helped in identifying whether functional devolution of powers from the states to the Panchayats had 
happened or not, and bring clarity to the accountability structure. This is a key element in local and 
rural governance which was the original intent of the legislation enacted in 1992. 
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Figure 2-2: Ponchayot Enterprise Architecture Framework Business Function Map 


The objective of Data Architecture was to define the major types and sources of data 
necessary to support the business in a way that is - understandable by stakeholders, complete and 
consistent, and stable. Data structures were defined and their use by the business functions and 
services were analysed. The entire process of data creation, processing, storage and utilisation was 
studied, gaps identified and data flows were redesigned to enable seamless integration of data from 
multiple sources and in the required format. 

Data architecture principles were established, existing databases (both master and 
transactional databases) were studied, data entity catalogue consisting of both common and specific 
data entities were defined. In order to understand how and which business processes used what 
data, the business processes were mapped to the data entities in the entity catalogue. This enabled 
identification of business processes with adequacy in data support. All of the above were 
consolidated and the data architecture stream of activity culminated in the development of the 
target enterprise data model. 

In the application domain, architecture principles were established and their relevance to the 
context was confirmed. The target logical view the applications was then defined enable a clean 
separation of concerns. The process view of the application was then developed and studied to 
understand the run-time implementation of the applications, and to identify interventions in areas 
like load distribution, availability, server side tuning, pooling and orchestration of activities. The 
application communication view was created to understand the communication between the various 
layers and modules in the applications and adoption of standard communication protocols. From the 
business functions and business services, all types of business users were identified and their 
preferred channel of access was mapped out. The entire application catalogue was analysed for 
commonalties and other aspects. Figure 2-3 shows the application architecture view. Each 
application was decomposed into its modules and functions, and mapped to business processes and 
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data entities. This created a three-way mapping between business, data and application perspectives 
to provide a more holistic integrated view and enabled identification of gaps, overlaps and other 
inefficiencies. 
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Figure 2-3: Panchayat Enterprise Architecture Framework Application Architecture View 

The applications were further analysed to identify reusable components, called the 
application building blocks (ABB). The intent being, ability to assemble future applications from a 
registry of application building blocks that is accessible to the entire organisation. In doing this, 144 
functional building blocks and 47 common building blocks were identified, through a process of 
listing, analysing, normalising and categorising. The integration aspects between the applications was 
captured in the integration view and this was important as several business services and business 
processes spanned multiple applications, and therefore required seamless exchange of data, 
coherent orchestration of application activities and support of multiple access channels to enable 
service delivery. 
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Given the vast and diverse geographical spread of Panchayats, the technology architecture 
focused on the critical aspect of deployment so that all the business services are available to the last 
mile. The principles for technology architecture were established to provide the broad contours and 
direction, and guide the process. To capture the largeness and complexity of the technology 
landscape, multiple views and viewpoints were developed and analysed to provide a holistic 
integrated perspective. These included covering aspects like environment and location, platform 
decomposition, network, computing and hardware, connectivity, security, application deployment 
and disaster recovery. 

Following the TOGAF, the PEAF was designed and developed provide the Panchayats the 
benefit of having a view on the structure of systems and infrastructure required to enable better 
delivery of services. Powered with this information and the methodology to analyse existing 
environments, PEAF was able to develop well-organised roadmaps and undertake cohesive rollout of 
systems and infrastructure for Panchayats. 

For more information about this please contact the National Informatics Centre in Delhi. 

ENTERPRISE ARCHITECTURE IN THE MINISTRY OF DRINKING WATER AND SANITATION [2014] 

The Ministry of Drinking Water and Sanitation (MoDWS), is the main institution of the 
Government of India, which complements the efforts of the State Governments in providing safe 
drinking water and sanitation to the rural masses of our country. Programmes for Drinking Water 
Supply and Sanitation have been under implementation ever since the inception of the first five-year 
plan. The Department of Drinking Water Supply (DDWS) under the Ministry of Rural Development 
undertook a Computerisation Project under the 9th Five Year Plan for effective planning, monitoring 
and implementation of various activities under the Rural Water Supply and Sanitation Sector. DDWS 
later was assigned the status of a Ministry in 2011 and was renamed as Ministry of Drinking Water 
and Sanitation. 

Today, the Ministry runs two social welfare programmes at the national level i.e. Swachh 
Bharat Mission - Gramin and Rural Drinking Water Programme. The objectives of both the 
programmes is to provide facilities in of sanitation and water in rural India by way of providing 
financial assistance to the State Governments as both water and sanitation are within their purview. 
The Ministry is aiming at implementing a strong e-Governance system to improve the effectiveness 
and efficiency of the programmes to achieve its vision and goals. 

The MoDWS Enterprise Architecture framework defines the methodology for development 
of all e-governance applications for the domain. It gives a comprehensive view of the enterprise from 
different perspectives and enables quick alignment of IT systems to its dynamic and ever evolving 
demands of business. The purpose of the enterprise architecture is to optimise across the enterprise 
the often fragmented legacy processes (both manual and automated) into an integrated 
environment that is responsive to change and supportive of the delivery of the business strategy. 

Effective management and exploitation of information through IT is a key factor to enterprise 
success, and an indispensable means to achieving competitive advantage. The MoDWS enterprise 
architecture addresses this need, by providing a strategic context for the evolution of the IT system 
in response to the constantly changing needs of the business environment. Furthermore, a good 
enterprise architecture enables the achievement of right balance between IT efficiency and business 
innovation. It allows individual enterprise units to innovate safely in their pursuit of competitive 
advantage. At the same time, it ensures the needs of the organisation for an integrated IT strategy 
are met, permitting the closest possible synergy across the extended enterprise. 
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TOGAF methodology was selected to build the EA framework for MoDWS. The reason for 
choosing TOGAF over other architectural practices is because enterprises seeking Boundaryless 
Information Flow™ can use TOGAF to define and implement the structures and processes to enable 
access to integrated information within and between enterprises. Any enterprise undertaking, or 
planning to undertake, the development and implementation of an enterprise architecture for the 
support of business transformation will benefit from use of TOGAF. 

The primary focus is laid on the TOGAF ADM. Grounded in enterprise architecture, TOGAF 
ADM is commonly referred to as the actual methodology for the execution of enterprise architecture. 
TOGAF is in its ninth version and has evolved from a pure IT architecture framework to an enterprise 
architecture framework. Figure 2-4 provides details about ADM as it was tailored. 



Figure 2-4: Tailored Version of TOGAF ADM Used in MoDWS Enterprise Architecture 


A series of interviews were conducted and a myriad of informal exchanges with individuals in 
the Ministry, NIC team and across various functions and roles in different states to solicit opinions, 
perspectives, observations, and suggestions surrounding MDWS's architecture design needs. 

A. Business Architecture: Business architecture articulates the existing business capabilities, 
governance structure, business processes, and business information. The business capabilities 
define what the Ministry and its line departments/field agencies do and the business process flow 
show how the capabilities are implemented. The business capabilities identified and documented 
in this report are a broader set, existing across all the states, confined to the states where the 
Public Health Engineering Departments (PHED) are responsible for rural drinking water supply 
and sanitation (90% of the states). The architecture framework was developed taking into 
consideration the functioning of the Ministry and the state PHEDs. The Business Architecture 
exercise is a prerequisite for architecture work in any other domain (Data, Application, and 
Technology). At the end of the exercise a target business architecture was established that 
described how the enterprise needed to operate to achieve the business goals, and respond to 
the strategic drivers set out in the business vision, in a way that addresses the request for 
architecture work and stakeholder concerns. The steps followed to arrive at the target business 
architecture are stated below: 


13 


NeST 




































Version 1.2 


India Enterprise Architecture Framework 


October 2017 


1. Study the MDWS Vision; 

2. Review business goals and strategies to understand the strategic objectives of the MDWS 
through their "Strategic Plan-2011-22-Rural Drinking Water" and "Rural Sanitation and 
Hygiene Strategy 2011-2022"; 

3. Arrive at the Ministry Vision Diagrams based on the strategic priorities the vision diagrams 
are arrived at; 

4. Understand the Institutional Framework and the key actors involved in attaining the vision; 

5. Assessing the current state and capabilities to understand the high level functions performed 
at various levels and carve out the business capabilities of the MDWS through these functions 
and processes in place; 

6. Envisioning the future state as in the strategy document for the Ministry of drinking water 
and sanitation; 


7. Compare Step 6 with Step 5 to identify gaps and create a heat map of the business framework; 

8. Highlight the impacted capabilities to attain the target state; and 

9. Suggest process enablers to attain the vision. 

The impacted capabilities mentioned in step 8 above, were depicted by generating a heat 
map of the current business framework state as given below in Figure 2-5. The 'High Gap' areas were 
identified and the impacted capabilities were handled for achieving the target state. 



Figure 2-5: MoDWS Current State Business Framework 


A. Application Architecture: The application architecture describes the applications supporting the 
business processes and functions in the business architecture and managing the data objects in 
the Information Architecture. In this section, all the applications present in the MDWS are listed 
out mapping to the business capabilities identified. A logical view of the target state of application 
is presented in this section and can be referred to for application development. 
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B. Data Architecture: This focusses on the organisational logical and physical information 
management assets. The goal is to identify and define the sources of information that support a 
given business capability to be fulfilled within the architecture. In this section, the entity 
relationship diagram is presented and the high-level data needs mapping to the business 
capabilities and actors are carved out. 

C. Technology Architecture: This focusses on mapping application and data components to tangible 
hardware and software models, catalogues, and matrices. 

D. Opportunities and Solutions: Based on the analysis performed in the above sections a technology 
roadmap was proposed. The MDWS has the ability to choose their projects and implement. 

Compliance & Benefits 

The Multi-tenancy based eGovernance systems for National Rural Drinking Water Programme 
(NRDWP 4 ) and Swachh Bharat Mission - Grameen (SBM-G, http://sbm.gov.in) are being aligned to 
facilitate aims & objectives of these two national level programmes under implementation in rural 
areas. The development of enterprise Architecture for Ministry of Drinking Water & Sanitation 
(MoDWS) has enhanced understanding of overall business environment, facilitated re-architecting 
process for resilient online eGovernance information system to meet business requirement to a large 
extent and identification of gap areas to be addressed as per priority of Ministry. 

For more information on this, please contact the National Informatics Centre in Delhi. 

E-PRAGATI: THE ANDHRA PRADESH STATE ENTERPRISE ARCHITECTURE [2014-15] 

e-Pragati, is a new paradigm. It is a mission centric approach and a framework, to galvanise 
the pan-government ecosystem by transcending boundaries to design and deliver services in a 
coordinated, integrated, efficient and equitable way that citizens and businesses demand and 
deserve, aimed to realize the Sunrise Andhra Vision 2029. Andhra Pradesh is the first state in India to 
develop a state-wide enterprise architecture. This is a pioneering development that will spur many 
such initiatives in the country. e-Pragati aims to guide and accelerate AP's journey to Government 
2.0. This is characterised by an integrated operating model, which enables collaboration between 
departments, to deliver personalised services via multiple channels where the citizen is a participant 
to an outcome-driven, transparent and accountable government. 

With delivering connected government as its primary goal, e-Pragati intends to make the 
Andhra Pradesh state government future-ready by transitioning from departmental stovepipes to a 
citizen-centred approach to public services achieved through transformation of the front, middle and 
back office operations. This necessitates collaborative working and information sharing between 
departments, forming a virtual / digital network organised around citizen services and their 
outcomes. Citizens, being an essential part of the ecosystem, are informed, engaged and involved to 
augment inclusiveness. The items of the e-Pragati manifesto are: 

• Single Entry, Multiple Use: Citizen details once entered or available anywhere within the 
government, are propagated through e-Pragati so that citizens do not have to provide them 
multiple times to avail services; 

• No Wrong Door: Citizens view the government as ONE entity, translating into citizens 
approaching any government service delivery channel for any government service; 

• Disintermediation and Re-intermediation: Services requiring coordination between multiple 


4 http://lndiaWater.gov.in 
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departments are taken up as a single case, and driven through to logical conclusion without the 
citizen having to approach the related departments individually; 

• Derive Insight, Deliver Foresight: Predict / pre-empt services that citizens need or are eligible 
for and trigger service delivery proactively (i.e. without the citizen even applying or requesting); 
and 

• Citizen Core, Mission Focused: Group services for categories of citizen stakeholders (e.g. 
farmers, students, patients, pensioners, senior citizens, civil servants, defence personnel etc.), 
possibly around life-cycle events and deliver them in a unified manner through government 
missions. 

Tenets for e-Pragati are codified as general propositions applicable across the Government, 
to facilitate decision-making particularly on contentious issues, exemplifying certain degree of 
practical wisdom. These principles are meant to define the overall contours of the enterprise 
architecture and form the first level of compliance. 

In order to realise the vision, it was imperative to elevate the present e-Governance initiatives 
to "transformation" level. With this end in view, the State Government established the Andhra 
Pradesh State Enterprise Architecture (APSEA). The APSEA is aimed to be a lever for transformational 
change in the way government services are conceived, designed, delivered and consumed. In 
alignment with TOGAF, the following four high-level architectures were designed: 

• Business Architecture seeks to re-engineer, integrate and transform the business functions of the 
33 departments and over 150 organisations of the State Government, along with the field offices 
and functionaries numbering over one hundred thousand and spread across the State; 

• Application Architecture seeks to critically examine the existing and the new applications needed 
to deliver the enhanced functionality, and regroup them adopting the principle of "Build-Once- 
Use-Many-Times"; 

• Data Architecture is the adoption of which ensures establishing data as a "Single Source of Truth" 
that is shared by all; and 

• Technology Architecture derives the benefits the latest technologies and standards and enhances 
efficiency through customer-centric behaviour. 

These four architectures, essentially drawn from TOGAF, form the 4 pillars of e-Pragati, and 
rest on the strong foundation of enterprise architecture governance. 

Target application architecture realises government functionalities as required by various 
users such as citizens, employees and businesses. These applications are standardised and configured 
on a unified delivery mechanism, and are accessible through multiple end user devices. The 
applications are categorised into common, group, cross-cutting and department applications. 

The target data architecture addresses the concerns related to data such as types of 
databases that should be operational across the system, how they are integrated, overarching data 
management framework that includes data delivery, data services, core architecture components 
such as data security, data access, lifecycle, migration and various data models such as conceptual, 
logical and physical. 

The target technology architecture is a collection of technology building blocks, positioned 
and/or sourced in such a manner so as to enable the state government to achieve the government 
vision. These building blocks provide and support the systems used by the government, both 
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software and hardware. The technology architecture is based on three building blocks - technology 
architecture vision, principles and standards with a layered architecture of access, distribution and 
core layer. Access layer provides for end user computing and management of desktops, laptops, 
smart phones, tablets, etc. Distribution layer takes care of how users get access to services and 
provide a service based architecture. Core layer manages the physical components of technology 
architecture like compute, storage, network and data centre. 

e-Pragati is not merely about modernisation of state's ICT infrastructure. It is designed to 
propel the state to the next level of Digital Economy. An important aspect of governments is that 
they are part of larger ecosystems. This is because governments exist at different levels, which 
despite belonging to potentially different political parties must come together to form a coherent 
whole. This is a real showstopper, as many architecture initiatives are plagued by political differences, 
contention for visibility and impact, and competition for resources and attention, all of which are 
disruptive and tiring. As part of visioning, state governments are recommended to factor these in 
and understand the overall ecosystem the architecture will be designed for and operate in. 
Government services transcend all levels and usually require close coordination between different 
parts of the ecosystem. By taking an ecosystem view, state governments would be able to envision 
the complexities involved, and therefore design appropriate strategies and interventions to address 
any emergent issues and constraints. 

Architecture analysis has been used to derive the programmes and initiatives. Figure 2-6 
shows the seventy-two architecture derived initiatives that form the implementation aspect of e- 
Pragati. These initiatives are prioritised and grouped into progressive waves. Initiatives associated 
with one another through dependency or shared outcomes were grouped into waves, and the waves 
were further prioritised based on business and operational inputs. Through the seventy-two 
initiatives the following goals are being aimed: 

• Citizen centricity: This refers to viewing governments with an outside-in perspective, i.e. 
understanding the requirements and expectations of citizens to become the pre-eminent guiding 
principle for all government policies, programmes and services. In short, this represents the 
service-dominant logic which requires governments to operate as one enterprise and organise 
themselves around citizen demands and requirements; 

• Common infrastructure and interoperability: This refers to the use of standards and best 
practices across governments to encourage and enable the sharing of information in a seamless 
manner. Interoperability is the ability of enterprises to share information and knowledge within 
and across enterprise boundaries. The underlying foundation for effective interoperability comes 
from standardised common infrastructure; 
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Figure 2-6: Architecture Derived Initiatives from e-Pragati at a Glance 


• Collaborative services and business operations: Connected government requires departments 
to collaborate. It is not difficult to uncover success stories about integration and interoperability 
at the technology level. However, to collaborate at the level of business services and functions 
requires political will. This is because collaboration at this level is disruptive leading to shallower 
stovepipes, elimination of redundant or overlapping services and discovery of common and 
shared services, which in turn result in redistribution of authority and control for some segments 
of the government; 

• Public sector (networked) governance: This refers to the decision rights, and the accountability 
framework required for implementing all other strategies for connected government. Good 
governance is a non-negotiable factor in the success of connected government, more so in 
countries that have multiple levels of governments (i.e. federal / central; state / provincial; and 
town / city) where various levels could be administered by different political parties; 

• Networked organisational model: This refers to the need to accommodate new organisational 
models wherein the enterprise (in the context of the WOG) is a network of relatively autonomous 
ministries and departments working in a coherent manner to deliver value to both citizens and 
businesses. This makes the government a networked virtual organisation (NVO) that operates 
seamlessly toward a common mission; 
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• Social inclusion: This refers to the ability of governments to move beyond horizontal and vertical 
integration of government service delivery to engaging the citizens and businesses at relevant 
points in the policy and decision-making processes. E-democracy and social inclusion ensure that 
delivery of government services is not a one-way exchange. Innovative ways of using technology 
to facilitate constituent participation and building a consultative approach are imperative for the 
success of connected government; and 

• Transparency and open government: This refers to the political doctrine which holds that the 
business of government and state administration should be opened at all levels to effective public 
scrutiny and oversight. In its broader construction, it opposes reason of state and national- 
security considerations, which have tended to legitimise extensive state secrecy. 
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3. A Primer to IndEA 

IndEA is a set of building blocks that State Governments can use to describe their future state 
of their e-Governance processes and systems. IndEA is a collection of architecture reference models. 
Broadly, reference models are documented best practices that help solutions delivery teams make 
effective design and technology choices. The purpose of the reference models is to increase 
standards adoption, speed up service design and delivery, and advance towards the target state 
architecture. 

a. IndEA as an Architectural Construct 

Many stakeholders are involved when considering complex systems such as those expected 
in governments. These stakeholders have many intertwining concerns pertinent to the system of 
interest. Their concerns cover the full lifecycle of the system, and their complexity calls for a 
framework to identify and classify the concerns into appropriate categories to enable systematic 
evaluation and resolution to architect and build such systems. 

An architecture framework contains information identifying the fundamental architecture 
constructs and specifies concerns, stakeholders, viewpoints, model kinds, correspondence rules and 
conditions of applicability. Enterprise architects can use an architecture framework to discover, 
describe and organise topics of interest (concerns) about the system at hand; they can further use 
architecture representation to clarify, analyse and resolve these concerns. The architecture 
description enables the enterprise architect to express an architecture. 

At the core of the ISO/I EC/IEEE Architecture Description Standard are viewpoints. A viewpoint 
comprises of conventions framing the description and analysis of specific system concerns. A 
viewpoint frames one or more concerns. The term concern refers to any topic of interest pertaining 
to the system. IndEA covers eight viewpoints, represented as reference models designed to enable 
government enterprises to build their own enterprise architectures. Key considerations that went 
into the development of IndEA include: 

• The imperative for state governments and other government enterprises to regularly define and 
reconfirm their vision, mission, goals and objectives with a medium to longer term perspective, 
and as far as possible within the constitutional framework, embrace the practice of master- 
planning and execution. This is a significant factor, as many a times, governments tend to be 
overly focused on operational fire-fighting. In other words, with IndEA the consideration is to 
balance reactive behaviours with proactive planning; 

• Proliferation of transactional services and more-than-needed focus on quantum of transactions 
rather than actual outcomes and impact on citizens and other stakeholders. There is a tendency 
among government enterprises to highlight quantity over quality, and extra-ordinary amounts of 
efforts expended to demonstrate that the government machinery is busy, further exacerbated 
by the high degree of overlaps and redundancies that exist (or are growing) due to fragmented 
thinking; 

• A review of eTAAL 5 reveals that services across the states tend to be very similar. This is deliberate 
given that all states in India operate under a single Union / Central Government, with a 
constitutionally guaranteed federated form of governance. Nearly 30 - 40% of services tend to 
be same or similar across states, yet there is little exchange of information or willingness to take 


5 http://etaal.gov.in/etaal/auth/login.aspx 
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benefits of economies of scale by combining, rationalising and organising the services. There is a 
significant scope for identification of common business capabilities, processes, streamlining, 
reduction in duplications leading to overall efficiency and effectiveness; 

• The Open Group's philosophy of Boundaryless Information Flow™ can only be achieved when 
end-to-end business flows with straight-through processing is supported by data standards and 
shared data hubs. A standard way of describing data, common taxonomy, data exchange 
framework, seamless sharing of data across government enterprises, and publishing government 
data to public-at-large to encourage new services in a collaborative manner are key 
considerations in the data domain. The ability to analyse the data in order to derive insights and 
aid decision making are equally critical; 

• As with government services and their underlying business processes, there is a general 
preference to build applications to automate and support one or at most a few services. The 
stovepipe approach that initiates at the service and business process layers continues to get 
entrenched at the application and system layers. There a noticeable apathy towards "looking- 
across" and even attempting to uncover common application capabilities and reuse. This is 
amplified by the fact that most state governments and other government entities tend to be 
dictated / directed by their vendors, who, needless to mention, come with their own vested 
interests and proprietary solutions; 

• The digitisation of government services depends on availability of ICT infrastructure that is 
reliable, ubiquitous and secure. The scope to achieve standardisation in this layer of the 
architecture is immense. There is a felt need, therefore, to provide a set of principles, standards 
and guidelines to steer state governments and government enterprises to design, procure and 
operate such infrastructure, and not be swayed by vendor priorities. This is a layer that can be 
consolidated and all benefits of standardisation accrued; 

• The need to govern a mix of business services that in some form touch governments at different 
levels (e.g. a federally funded, state government administered and local government delivered 
service) bringing in high level of complexity, wherein there is ambuguity as to who the actual 
customer is, its role and accountability; 

• With explosive growth of digital channels, devices and citizen expectations for providing services 
that are "anytime, anywhere, anyform" and the inter-connectedness of everything, the 
imperative to understand the security (and privacy) aspects cannot be overlooked. Mission 
critical assets need to be protected through a series of multi-layered, defence-in-depth 
interventions that are essential to ensure the critical services and information are available in the 
right form, at the right time, to the right people, for the right reason and in the right place; and 

• The effectiveness of the above layers or perspectives is amplified only when there is an underlying 
framework for integration. Fulfilment of mission necessitates end-to-end business processes, 
that are supported by seamless access to data from multiple sources, orchestration of application 
capabilities across multiple applications, operating on common and shared infrastructure (both 
on premise and on the cloud), functioning in a secure way while still protecting privacy of the 
citizens-at-large and government assets. Therefore, the ecosystem that is connected government 
is realised only when enabled by an effective integration mechanism. 

A few contemporary scenarios where state governments and other government entities can 

benefit from enterprise architecture include the following, but are not limited to: 
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• Government transformation initiative which demands efficient coordination between strategies, 
policies, processes, services and organisational capacity to absorb change; 

• Enhancement of service delivery across the government in order to create services that are 
citizen-centric, cross-departmental, end-to-end and outcome based; 

• Rationalisation of data across the government to enable an integrated perspective, facilitate 
open data and transparency, and departmental collaboration and compatibility; 

• Coordination of all ICT initiatives under one umbrella to get a better holistic perspective, boost IT 
planning effectiveness and optimise costs and investments for better returns; 

• Implementation and ICT enablement of government process reengineering to provide multi¬ 
channel service delivery in a manner that increases digital take-up and completion rates; 

• Ensuring that government applications and systems provide end-users with information they 
need to make decisions and influence government operations; 

• Improving the execution capability of policies and other interventions to achieve better planning 
and anticipate budgetary impacts on the government and enabling ICT systems; 

• Adopting new and emerging technologies to augment government efficiency and thereby attract 
investments; and 

• Building an ecosystem for the digital economy to boost shared prosperity, by leveraging ICT for 
employment and growth. 

Active endorsement by the political leadership, cabinet and bureaucracy are imperatives for 
success. In the context of e-government, India is on the cusp of growth with Digital India stimulating 
further initiatives and advancements. The adoption of enterprise architecture in the government is 
a complex and eclectic mix of enabling factors, challenges, impediments which are political, 
environmental, social, technological, legal and operational in nature. A culmination of these 
multitude of factors creates a complex system that makes it difficult for citizens and businesses to 
get things done. 

b. IndEA Reference Models 

The primary objectives of IndEA RMs are to: 

• Capture and codify current knowledge and experience in a consolidated form for ready reference 
to anyone who is interested to understand this subject; 

• Kick start enterprise architecture initiatives across India, covering entire state governments and 
other government / public sector entities; 

• Enrich the procurement process and provide greater leverage to government enterprises in 
managing their vendors; 

• Document issues and concerns contextual to India, in manner such that the finer nuances of 
governance are captured and factored in; 

• Support India's transition towards digital governance and knowledge economy as envisaged in 
the Digital India initiative. 

With these objectives, the eight reference models have been developed as shown in Figure 
3-2 (see Part [I] IndEA Framework for details). 
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Figure 3-1: The IndEA Reference Models Normative View 
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4. Using the IndEA Framework 

This section elaborates how the reference models can be used. Taking the TOGAF® 
Architecture Development Methodology (ADM) as the base, each phase is summarised and the use 
of relevant Reference Models is described. Readers are referred to the detailed objectives, steps, 
inputs and outputs of the TOGAF ADM in the main TOGAF standard. They are not repeated here to 
maintain brevity. 

a. Architecture Development in a Multi-level Enterprise 

Government enterprise architecture follows a multi-level approach to account for different 
layers of government bodies. Business services should be analysed for inter-departmental linkages, 
and automation/digitisation and infrastructure requirements. Different viewpoints should be linked 
to ensure a 360-degree view of the citizens and businesses. Service design must be citizen centred 
(i.e. services are anchored around key stakeholders-citizen, farmer, student, land owner, senior 
citizen, beneficiary). Service delivery is to be supported by deep collaboration between departments 
in terms of information flow, application interaction and common infrastructures. State governments 
and other government entities are advised to traverse the phases of the ADM in a structured manner. 
The use of the IndEA across the phases have been elaborated. The following figures 6 depict the key 
activities across the ADM phases. Figure 4-1 shows the activities when the state government is aiming 
to build a state government wide enterprise architecture, i.e. at the WOG level. 



Figure 4-1: TOGAF ADM Phose-wise Activities for Government-Wide EA 


6 http://www.igi-global.com/book/enterprise-architecture-connected-government/62630 
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When the state government has its own government-wide enterprise architecture, that then 
forms an input to individual departmental enterprise architectures. This approach ensures that the 
departments while conforming to the overall state enterprise architecture are still able to retain their 
autonomy and operational independence, thereby reflecting the governance structure. This 
approach also encourages certain forward-thinking departments to develop their own enterprise 
architectures even before the state enterprise architecture is developed. 

Figure 4-2 shows the ADM activities for an individual government agency to develop its 
enterprise architecture, which in conformance with the WOG enterprise architecture shown in Figure 
4-1. The ADM cycle in Figure 4-2 should be seen triggered by and subsequent to the ADM cycle shown 
in Figure 4-1. 
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Figure 4-2: TOGAF ADM Phose-wise Activities for Agency EA 


The architecture-derived initiatives and programmes will need to be consolidated to build 
solutions. These form the third level of ADM cycle, representing implementation. This is depicted in 
Figure 4-3. It is most likely that state governments may engage external implementation partners to 
perform this cycle, e.g. system integrators. Therefore, the specifications derived from earlier two 
cycles (Figures 4-1 and 4-2) should form a critical part of the procurement process. The significant 
portions of the architecture description should be incorporated in the tender / RFP specifications. 
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The use of IndEA is essential at all the three levels (shown in Figures 4-1, 4-2 and 4-3). 
Overtime, it is expected that the state governments may enrich the reference models, by 
incorporating portions that may be relevant to their specific contexts. This retains the vitality for the 
reference models, keeping them fresh and relevant, by regularly including changes. 
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Figure 4-3: TOGAF ADM Phasewise Activities for Solution Architecture 


Figure 4-4 7 shows how IndEA Reference Models are positioned along with state enterprise 
architectures in the overall national context. The subsequent sections describe the use of IndEA in 
the various phases of the ADM, along with one phase on Conceptual Solution Architecture (covering 
Figure 4-3) which is an extension to the standard ADM. 


7 http://www.igi-global.com/book/enterprise-architecture-connected-government/62630 
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Figure 4-4: IndEA vis-a-vis State Enterprise Architecture in the National Context 

PRELIMINARY PHASE 

This purpose of this phase is for state governments and other government entities desirous 
of embarking on enterprise architecture to prepare and get the entire ecosystem ready. As part of 
this phase, organisations are recommended to study and understand the Reference Models, their 
purpose, and implications. It is important to study all the eight models and the preparation and 
information needed to demonstrate conformance. If an external vendor is being used for purposes 
of building the enterprise architecture, then they too need to be fully apprised of the reference 
models. In such a scenario, it is strongly advised that state governments and other government 
entities direct the vendors to tailor their respective approaches and methods to weave-in the 
Reference Models and prepare to demonstrate conformance at an appropriate juncture. 
Furthermore, if a commercial EA tool is being used then it would be prudent and timely to check and 
reconfirm how and to what extent is the tool support for IndEA. Any configuration of the tool, 
including relabeling terms, should be done at this stage. The core team should attend tool 
familiarisation sessions. 

The Reference models also include architecture principles. This is a good time to revisit the 
standard principles, and check for their adequacy and make any revision required. See Figure 5-1 for 
activity-wise mapping. 

The key questions to be addressed in this phase include: 
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1. What is your organisation's strategic situation? 

2. What are the most fundamental triggers to embark on the enterprise architecture initiative? 

3. How is this going to impact the state's overall governance, that is visible to the citizens? What 
difference will this make to the citizens' quality of life? 

4. What level of internal capacity and knowledge is needed? In what areas is this required to be 
augmented by external expertise / consultants? 

5. What is the scope of the enterprise in this context? What is scope of enterprise architecture? 

6. What body of knowledge is accessible that will be of utility? 

7. What is being aimed to achieve through this journey? Is there executive agreement and 
sponsorship? 

8. What resources and tools will be needed? Are they accessible? 

9. Have awareness and familiarisation sessions been conducted? Who have participated in these? 

10. What governance and legal frameworks (if any) are useful during this endeavour? 

11. Have the governance committee, core team, working teams been constituted, along with their 
terms of reference? 

12. What is the acceptance criteria? Who is the signing authority? 

13. Is there a clear common understanding on how enterprise architecture is going to be used and 
maintained once it is in place? 

The suggested outputs from this phase include: 

• Business Vision and Mission 

• Organisation Diagnostic Report 

• Architecture Principles 

• Architecture Scope and Programme Plan (Outline) 

• Architecture Governance Strategy (Outline) 

• List of Security Policies and Standards 

• Security Vulnerability Analysis Report 

• Security Assumptions and Boundary Conditions Report 


PHASE A: ARCHITECTURE VISION 

In this phase the architecture project scope, initiation of the architecture development cycle, 
identification of stakeholders, their concerns, business requirements, business goals, evaluation of 
business capabilities, target architecture value propositions, architecture principles are performed or 
established. Within the scope of activities and recommended outputs for this phase, the 
Performance Reference Model is the primary one to be used. Additionally, certain aspects from the 
Business Reference Model and Governance Reference Model should be used in this phase. IndEA 
does not prescribe the overall vision and mission for the states or any government entities. This is 
deliberate as it is expected that every organisation building its enterprise architecture will define its 
own business vision and mission to suit its priority and direction. The top leadership of the state 
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governments (comprising of the lawmakers and bureaucrats) are critical to define the state vision 
and mission. For these to be realised, the states are guided to define their goals and objectives. The 
PRM recommends the use of UN's Sustainable Development Goals (SDG) 8 as the basis of defining 
state / organisation specific goals and objectives. It is to be noted that all of the 170+ goals in SDG 
may not be suitable for a state or a government entity. The IndEA identifies the fifty most relevant 
ones, and filtering out the rest. The process of establishing goals with SDG as the basis, deriving 
objectives and KPIs is described in the PRM. One of the key outputs of this phase is to define the key 
performance indicators (KPI). The PRM explains the process to define KPIs, provides the most 
fundamental performance principles and critical measurement dimensions like KPI type, frequency 
of measurement, actions to be taken in case of deviations. Suggested KPIs, organised by domains and 
departments are provided as guidance. The state governments and other entities are expected to 
use them as reference and define their own ones. The critical part of PRM is to define and 
differentiate outputs and outcomes, as the fundamental approach of PRM is to demonstrate that 
KPIs do positively influence goals and fulfillment of objectives, leading to achievement of vision and 
mission. See Figure 5-1 for activity-wise mapping. 

The key questions to be addressed in this phase include: 

1. Is there a clear and accepted vision and mission in place, that is both aspirational and 
transformational? 

2. Is there a formal architecture project plan? Does this identify the core outputs, critical milestones 
and important timelines? 

3. Which organisational entity is tasked with this initiative? What is their level of authority to 
implement? 

4. Flave the vision and mission been translated into actionable goals and objectives? 

5. Which other departments should be involved? Flave the SPOCs been identified? What is the 
expected interaction mechanism? 

6. Are the business goals, business drivers and business constraints defined and implications 
understood? 

7. Have the performance outcomes been established and agreed upon? 

8. Have the architecture principles been established and agreed upon? 

9. What are the potential risks, and have the mitigating activities been elaborated? 

10. Is there a formal statement of work that is accessible to all relevant parties, including external 
consultants (if any)? 

The suggested outputs from this phase are: 

• Architecture Scope and Programme Plan (Detailed) 

• Business Goals and Objectives 

• Key Performance Indicators and Outcomes 

• Environment Analysis Report (Current Business and IT Landscape) 

• High-Level Architecture Requirements 


8 https://sustainabledevelopment.un.org/content/documents/118Q30fficial-List-of-Proposed-SDG-lndicators.pdf 
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• Security Environment (Physical, Business, Regulatory) Analysis Report 

• Security Conformance Action Plan 

• Disaster Recovery and Business Continuity Action Plan 

• Risk Management Strategy and Mitigating Activities 

• Communication Plan 

PHASE B: BUSINESS ARCHITECTURE 

This phase primarily covers the approach to realise the vision and mission, through the 
development of business architecture. The validated business principles, business goals and business 
drivers are critical components of this phase. The business principles are elaborated. The current and 
target business architectures are developed and documented, gaps between the two perspectives 
are analysed for identification of opportunities. These opportunities are then utilised to create high 
level technical requirements, and the first cut of the architecture roadmap. The BRM is the primary 
reference in this phase, while the PRM forms the secondary reference. Broad reference to the other 
reference models are more to understand the impact of business architecture to the technical 
domains, so that the high level technical requirements can be identified. 

The BRM captures the "business of government" through the business services states and 
other government organisations provide to citizens, businesses and other stakeholders in the 
ecosystem. Business services (G2C, G2G, G2B and G2E) are critical, as they are the means by which 
governments interact with citizens and businesses. Development of current service catalogue, the 
process of service prioritisation, service rationalisation and simplification of service portfolio leading 
to the creation of target service catalogue is guided by the BRM. The recipients of the services (service 
beneficiaries) and service outcomes are also covered in the BRM. These form critical components of 
the target business architecture. The target business architecture is linked to the PRM through the 
service outcomes impacting the KPIs. The target business architecture is elaborated through the 
underlying business processes that realise the services, and identify any need for process 
reengineering. The processes provide input to identify the supporting data requirements and 
governing business rules, linked to the DRM and other reference models. 

A key deliverable from Phase B is the architecture definition document which takes input from 
the BRM, to a lesser extent from the PRM and GRM, and covering the linkages to the technical 
domains captured in the other reference models. See Figure 5-1 for activity-wise mapping. 

The key questions that should be addressed in this phase are: 

1. How many services does the state offer / deliver to various stakeholders? 

2. In the cumulative service list, how many belong to the following types: 

a. Government to Citizen (G2C) 

b. Government to Business (G2B) 

c. Government to Employee (G2E) 

d. Government to Government (G2G) 

3. What proportion of services are direct, indirect (general) and obligations: 

a. Direct (for direct benefit of an individual based on need). 
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b. Indirect (general, for general benefit of all in the community). 

c. Obligations (placed on certain individuals for the indirect benefit of all the community). 

4. What proportion of services are currently automated / digitised as e-services? 

5. What channels are used to deliver the services? 

a. Face-to-face aggregate (i.e. services centres / one stop shop) 

b. Face-to-face in respective departments 

c. Automated aggregate (i.e. centralized pan-government portal) 

d. Automated departmental (i.e. departmental portals) 

e. Mobile / handheld devices (i.e. m-services) 

f. Outsourced service provider (service brokers) 

6. Flave the services been subjected to any form of prioritisation, specifically to identify the 
important and critical services? 

a. If yes, what is the prioritisation approach / method adopted? 

7. Flave the services been rationalised (i.e. overlaps and redundancies identified and eliminated as 
needed)? 

8. What supporting documentation is available pertaining to the services? 

a. If yes, are they adequately granular? 

b. If yes, are they appropriately recent / latest? 

9. What is the approach used to identify, launch and refresh services? 

a. In past five years how many services have been abolished or discontinued? 

b. In past five years how many new services have been initiated / launched? 

10. Flow is service performance measured? 

11. Is the service performance linked to citizen feedback / satisfaction? 

12. Are there services that are: 

a. Department specific (i.e. all aspects of the service are fulfilled by one department in 
totality, with no dependency on any other department). 

b. Common to the entire state government (i.e. services consumed by all departments of 
the state, requiring inter-departmental interaction). 

c. Group / cluster specific (i.e. all aspects of the service are fulfilled by collaborating 
departments belonging to a logical group / cluster - e.g. health cluster, education cluster, 
social welfare cluster etc.). 

d. Cross-cutting (i.e. which have a lead department triggering the service, but need various 
levels of involvement by other departments in an orchestrated manner for fulfilment). 

13. In the past five years, how many services have been reengineered? 

14. Flow does the government view its role pertaining to services? 
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a. As an end-to-end service provider. 

b. As a partial service provider (i.e. some activities within the service flow are performed by 
external entities). 

c. As a service assurance manager (i.e. entire delivery is outsourced, and the government 
uses SLAs to manage vendors). 

15. Does the government have an integrated service delivery approach in place? 

a. How are the digital and non-digital interactions integrated? 

16. Do the services have a common look, feel, tone and function? 

17. Are there services that are not attributable to any mission and goal, but still active for legacy 
reasons? 

The suggested outputs from this phase include: 

• Current Business Architecture 

• Target Business Architecture 

• Gaps and Opportunities Analysis Report 

• Business Service Catalogue 

• Business Process Analysis Report 

• Current Security Process Analysis Report 

• Target Security Process Analysis Report 

• Detailed Architecture Requirements 

PHASE C-l: DATA ARCHITECTURE 

This first sub-phase within Phase C of TOGAF ADM covers data and information aspects. Data 
is the new currency in the digital world. For governments to encourage and support the concept of 
"one government", the underlying data is a critical success factor. Through this sub-phase the target 
is to enable data standards, data definition and data exchange. The first and foremost activity in this 
phase is to find / discover data that are required and needed, the second is to find a common agreed 
way to describe the data. Data discovery and description is deeply influenced by business and 
operations, therefore context is essential for data to be meaningful and usable. As part of defining 
the data architecture, organisations are advised to build on the architecture principles provided in 
the DRM. Usually, current data architecture should consist of identifying the core applications and 
systems and subject them to reverse engineering to identify the underlying data entities. These 
current data entities should be captured together to understand the relationships and interactions. 
The usual shortcomings with regard to current data include - (a) incomplete data; (b) inconsistent 
data integrity; (c) overlaps and repeated data; (d) missing data context; (e) isolated data (no sharing); 
(f) missing links to business services; (g) weak or missing data governance: and (h) no clear data 
ownership and accountability. In defining the target architecture, the DRM should be used to build 
meta-data standards, data definition, data sharing and data context. The core entities that the DRM 
lists should be the first port of call. Only state and organisation specific data should be defined new. 
Available data dictionaries in various domains (e.g. Health, Insurance) should be closely followed and 
adopted, to avoid reinventing same data again. 
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Data architecture analysis should also categorise certain common data across the government. These 
include data pertaining to people, businesses, land, things. They are candidates to be become "data 
hubs". Data should be a reusable asset, that is mission-critical. This should be augmented with strong 
and effective data governance. The architecture definition document in this sub-phase should cover 
issues like - who / which process creates the data, how does the data flow, where does it get used, 
in what format does it get created, who owns the data, who is allowed to modify the data and under 
what circumstances, which is the single definitive source for this data. Governance of data must 
factor in the organisation's structure, roles, responsibilities and administration. See Figure 5-2 for 

activity-wise mapping. 


The key questions that should be addressed during this phase include: 

1. Currently, where does the data reside? 


a. Entirely in respective applications and systems 


b. Partly in respective applications and systems, partly in common data repositories 

c. Entirely in common data repositories 


2. Are there services wherein there are requirements to share and exchange data between 

departments? If yes, what is the mechanism used for data sharing and exchange? 

3. Have any common and shared data been identified? 


4. Have any kind of data standards been defined and adopted (i.e. standards pertaining to data 

definition, data sharing, meta-data)? 


5. Is any industry level data standards being used? 


6. How many applications have their data schemas readily available? Are these schemas used in 

managing data? 


7. What is nature of data that currently exists? 


a. Parliamentary and legal data 

n. Employment, labour and 

b. Public expenditure and budgeting 

opportunities data 

data 

o. Procurement data 

c. Environmental data 

p. Works, contracts and vendor data 

d. Demographic data 

q. Feedback and grievance data 

e. Socio-economic data 

r. Security data 

f. Health and well-being data 

s. Governance and administration 

g. Geographical data 

data 

h. Transportation data 

t. Housing data 

i. Agriculture and aquaculture data 

u. Rural development data 

j. Industries and business data 

v. Tourism, sports and entertainment 
data 

k. Government assets data 

1. Resources and revenue data 


m. Education and skills data 
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8. Are there any requirements to combine data of different kinds and from different sources, and 
use them for decision making? 

The suggested ouputs from this phase include: 

• Current Data Architecture 

• Target Data Architecture 

• Gaps and Opportunities Analysis Report 

• Data Dictionary / Catalogue 

• Data Governance Strategy and Action Plan 

• Data Asset and Access Privilege Report 

• Data Flow and Lifecycle Report 

• Information Classification Report 

PHASE C-2: APPLICATION ARCHITECTURE 

This second sub-phase within Phase C of TOGAF ADM covers the IT systems and applications 
used to automate business services and their underlying business processes. The systems and 
applications are the most visible and utilized portion of the enterprise architecture, as they manifest 
how interactions take place. The ARM provides specific inputs by way of suggested application 
architecture principles. The current application architecture is developed and analysed. The most 
important observable characteristic in the context is that applications in the government machinery 
usually reflect the fragmented and stovepipe thinking that exists in the business operations. The most 
important part of using the ARM to build the target application architecture is to analyse the 
application catalogue and identify application capabilities. The ARM classifies applications as core, 
common, group and departmental applications. Reorganising applications through a process of 
decomposing, understanding, rationalizing and consolidating is a critical part of the developing the 
target application architecture. The critical idea is to ensure that individual ministries and 
departments are able to maintain their required autonomy (a constitutional mandate) while also 
taking advantage of economies of scale in an ascending manner. The use of ARM will therefore get 
all states and other government entities to have the core set of applications at the minimum. This 
means certain critical services will be automated through this common core. On top of the common 
core, the other common, group and departmental applications (based on business priorities and 
availability of data) are to be built and commissioned in a structured manner. To aid adoption, the 
ARM provides list of common, core, group and departmental applications. 

The development of application architecture in this phase also requires elaboration and 
clarity with regards to non-functional (or quality) requirements, and adoption of relevant standards 
for the various layers in the application architecture. This phase is a critical success factor as these 
underlying applications are how the concept of a federated and integrated government is achieved. 
This is what is physically visible. The organised catalogue of applications in the target application 
architecture should be able to support usage scenarios such as: 

• Publish usage scenarios, which represent publishing document or data in a way that allows for 
electronic access over internet, typically using a web site or a web portal; 
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• Interact usage scenarios, which allow consumers of the services to interact with the government, 
but not in a way that involves transactional processing; for example, ability to exchange emails 
or to fill out feedback forms fall into this category; 

• Transact usage scenarios, which represent interactions containing transactional component, 
such as on-line data entry or purchases; and 

• Integrate usage scenarios, which involve integration of services made available by eGov with 
other services or data (typically, from other sources) to produce new services. These scenarios 
involve publishing of eGov services (typically, as Web Services) and mashups of services with 
other services or data sources. 

In order to support these usage scenarios, it is imperative that the applications integrate and 
interact with one another, in an orchestrated manner so that the service interactions become 
seamless. This is covered in the IRM. As a consequence of "organic" and gradual proliferation of 
applications in government entities, the most prevalent current way of integration is point-to-point. 
This is a workable solution if the number of applications is less than ten. Anything over and above 
ten, makes point-to-point integration a spaghetti. As the way forward, the states are encouraged to 
adopt middleware based and hybrid integration approaches. See Figure 5-2 for activity-wise 
mapping. 

Some of the indicative scenarios for integration, along with recommendations are mentioned below: 

Scenario 1: A small number of legacy applications, designed and developed independently with 
diverse technologies, largely operating in silos reflecting business operations, within the confines of 
single ministry or department, and little need for external interactions. 

Recommendation: Use P2P integration for specific needs. 

Scenario 2: A large number of a mix of legacy and new applications, designed and developed 
independently, requiring high degree of business and operational integration, within the confines of 
a single ministry or department or organisation, and little need for external interactions. 

Recommendation: Use ESB / hub-and spoke approach to accommodate high degree of intra- 
organisational integration. 

Scenario 3: A large number of a mix of legacy and new applications, designed and developed 
independently, requiring high degree of business and operational integration, requiring extensive 
interactions with other ministries or departments or external stakeholders in the ecosystem. 

Recommendation: Adopt a hybrid approach, i.e. ESB for interactions within the ministry or 
department, and specific application capabilities exposed as APIs for all interactions with external 
entities. 

The key questions that should be addressed in this phase using the ARM and IRM are: 

1. How many applications are in the current portfolio? 

2. How many applications are in active use? 

3. How many applications are standalone (i.e. applications that require no interaction with any 
other application in the portfolio)? 

4. How many applications are in the current portfolio? 

5. How many applications are in active use? 
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6. How many applications are standalone (i.e. applications that require no interaction with any 
other application in the portfolio)? 

7. Are applications evaluated for performance? If yes, how is this information used? 

8. Are there applications that need interaction amongst themselves? 

a. If yes, what interaction mechanism is used? 

i. Manual / data entry 

ii. Simple data transfer 

iii. Screen scraping 9 

iv. Point-to-point 

v. Middleware integration 

9. What are the primary reasons for applications to interact? 

10. What is the pre-dominant application development policy - build or buy? 

11. Where are the applications hosted? 

12. Are there application principles established and enforced across? 

13. What is the approach used to categorise or group applications? 

14. Has there been any concerted effort to modernise the applications? If yes, what the most 
prevalent modernisation strategy? 

a. Refactor 10 

b. Re-host 

c. Replace 

d. Re-architect 

e. Re-interface 

The suggested ouputs from this phase are: 

• Current Application Architecture 

• Target Application Architecture 

• Gaps and Opportunities Analysis Report 

• Application Catalogue / Portfolio 

• Application Development Strategy 

• Application Integration Architecture 

• Application Classification Report 


9 Screen scraping is the process of collecting screen display data from one application and translating it so that another application can display it. This is normally 
done to capture data from a legacy application in order to display it using a more modern user interface. 


10 A disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour. 
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PHASE D: TECHNOLOGY ARCHITECTURE 

In this phase, the technology infrastructure aspects are covered. The role of TRM in this phase 
is crucial, and this is the architecture layer that benefits the most from standardisation. Given the 
current technology landscape that is covered with a plethora of vendor products, the need for 
standardisation cannot be overstated. For most governments, technology modernisation and 
standardisation is a low-hanging fruit, usually vendor-influenced. The use of IndEA TRM can be 
augmented with the knowledge of TOGAFTRM. 

The IndEA TRM identifies the technology categories, domains and relevant applicable 
standards. Usually, due to procurement and adoption of ICT at different times and by different people 
results in technology diversity. For state governments and other government entities ICT is not the 
core business. Therefore, it is not area where governments need to experiment and explore with new 
technologies. Their primary job is governance. Given this scenario, the two priority areas that state 
governments are advised to consider are technology modernisation and technology standardisation. 
When analysing the current technology architecture and developing the target technology 
architecture, state governments should refer to the TRM which covers ways to structure the 
technology layer, provides guidance on technology standards and their applicability, factoring in 
Government of India's priorities and preferences (e.g. use of Open Source, and Cloud First). 

IT4IT™ is a reference architecture for the business of IT, and technology infrastructure is a 
major component of this framework. IT4IT covers the entire IT Value Chain including Plan, Build, 
Deliver and Run through four value streams, namely: strategy to portfolio, requirement to deploy, 
request to fulfil and detect to correct. See Figure 5-2 for activity-wise mapping. 

Major questions that need to be addressed in this phase include: 

1. What is the extent of technology standardisation? Is technology diversity an issue to be 
addressed? 

2. Is there a list of technologies currently in use within the government? If yes, when was this last 
updated / revised? 

3. What steps are in place to ensure that the technology used within the government remains 
relevant and future-ready? 

4. Is the current technology in use within the government, adequate to meet current and future 
needs? When and where are the constraints? 

5. Has technology audit been conducted to ascertain the technology debt? Is this hurting, both 
operationally and financially? 

6. Are technology assets located in-house and in-sourced? What portion is out-sourced? 

7. Is there a technology service catalogue? Is this extensively used to plan, design and deliver 
technology capability to the line departments? 

8. How well is the network topology understood and used as an input for decision making? 

9. Is the link between technology and application layers documented and understood? Is this 
mapping used to identify gaps, overlaps and opportunities 

The suggested outputs from this phase are: 

• Current Technology Architecture 
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• Target Technology Architecture 

• Gaps and Opportunities Analysis Report 

• Technology Portfolio 

• Technology Modernisation Strategy 

• Security Technologies Catalogue 


ADDITIONAL PHASE: SECURITY ARCHITECTURE 


This is not a separate phase in TOGAF ADM, usually the security aspects being implicit and 
subsumed within Phases B, C and D. However, given the emerging criticality of cybersecurity in the 
digital paradigm, IndEA has made security architecture a separate domain, thus reflecting its 
importance in the new normal. In order to show its close relationship with the other architecture 
domains, Figures 5-1, 5-2, 5-3 and 5-4 map security architecture to ADM activities in Phases B, C, D 
and extensions. 


The two major drivers for security are Risk and CIA (Confidentiality, Integrity, Availability). 
IndEA SRM covers these factors comprehensively. Keeping in view of this additional phase, state 
governments should use the layers identified in the SRM, and as part of current state analysis build 
a portfolio of security controls in place. Such controls are most likely scattered over the different 
architecture layers of data, application, integration and technology. The business drivers should 
ideally be covered as part of Phase B, business architecture. In general, in the current scenario 
security aspects tend to be - reactive, vendor driven, product centric and technology focussed. 

Developing the security architecture (the target view) should start with defining security 
architecture principles. The IndEA SRM provides principles covering Risk and CIA. The impact of Cloud 
and SOA on security also needs to be covered. From a senior management perspective, the following 
are key to defining good security architecture: 

• What would a serious cyber security incident cost our organisation? 

• Who would benefit from having access to our information? 

• What makes us secure against threats? 


• Is the behaviour of employees enabling a strong security culture? 

• What is our readiness to respond to a cybersecurity incident? 

In defining the target security architecture, the following need to be considered and factored in: 


• Assets that need to be secured and 
protected; 

• Goals and objectives of securing and 
protecting the assets; 

• Risks and opportunities involved; 

• Processes required to achieve the level of 
security desired; 


• People and organisational aspects of 
security; 

• Locations where the security interventions 
need to be taken; and 

• Time aspects that will impact the security 
interventions. 


A critical aspect of security architecture is the ability to pre-empt and deal with insider 
threats. The focus, if at all, is to secure and protect against external threats. Figure 4-5 (Source: 
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Understanding Insider Threats; Nurse, J.R.C et al in Workshop on Research for Insider Threats [WIRT] 
2014 11 ) models the framework for characterizing insider attacks. 
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Figure 4-5: Framework to Characterise Insider Threats 


The following security controls and interventions should be considered by state governments 
and other government entities: 

1. Application whitelisting of permitted / trusted programs. 

2. Periodic patching of applications, with the latest versions. 

3. Periodic patching of operating system vulnerabilities. 

4. Provide administrative privileges to a select few, purely based on roles and accountabilities. 

5. Automated dynamic analysis of email and web content. 

6. Host-based intrusion detection and prevention system to identify anomalous behaviours. 

7. Network segmentation and segregation, to isolate portions in case of incidents. 

8. Multi-factor authentication, especially for remote access (e.g. via VPN). 

9. Software-based application firewall to block both incoming and outgoing network traffic. 

10. Centralised logging of successful and failed computer events. 

11. Centralised logging of allowed and blocked network activity. 

12. Email and web-content filtering. 

13. Web-domain whitelisting for all domains. 


11 https://www.cs.ox.ac.uk/files/6576/writ2014 nurse et al.PDF 
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14. Workstation and server configuration management based on standard operating environment, 
and disabling unneeded / undesired functionalities. 

15. Heuristics based anti-virus software. 

16. Denial of direct internet access for workstations, with clear process for exceptions. 

17. Enforce a strong password policy covering complexity, length and validity aspects. 

18. Continuous user awareness and education. 

19. Restrict use of removable media, external storage and other devices from workstations. 

20. User application configuration hardening to disable running of internet based code, untrusted 
macros etc. 

The suggested outputs from this phase are: 

• Security Policies and Regulations 

• Security Stakeholders / Actors and Priveleges 

• Threats Analysis Report 

• Security Incident Impact Analysis Report 

• Security Metrics and Monitoring Plan 

• List of Applicable Security Controls 

• User Authorisation Policies 

PHASES E & F: OPPORTUNITIES & SOLUTIONS AND MIGRATION PLANNING 

There is very little direct use of the reference models. Indirect use of the reference models is 
covered by the Preliminary Phase and Phases A through D. This is attributable to the fact that, in 
general, reference models are extensively used during architecture conceptualisation, architecture 
elaboration and architecture governance. It is also useful for architecture evaluation. 

The suggested outputs from these phases are: 

• Consolidated Gaps and Opportunities Analysis Report 

• Consolidated Target Architecture Description 

• Architecture Scope and Programme Plan (Updated, if needed) 

• Architecture Implementation Roadmap 

• Communication, Advocacy and Training Material 


PHASES G, H & REQUIREMENTS MANAGEMENT: 

After the creation of the implementation roadmap. Phase G of ADM covers activities required 
for implementation programme governance. The GRM is the primary reference to be used in this 
phase. The GRM provides guidance on the mode of governance, and mechanisms to ensure that the 
decision rights and accountablities are clear and assigned to the right stakeholders. These should be 
part of the architecture governance strategy. Success of the enterprise architecture stems from the 
fact that the blueprint in adopted. Typically, EA can be used for strategy execution, programme 
management, IT investment decisions etc. The details of how EA can used, should be elaborated in 
the architecture adoption plan. Phase H, architecture change management is where steps are taken 
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to ensure that- (a) changes are managed in a structured manner during implementation; and (b) the 
reference models and EA blueprints are kept updated by incorporating a process of periodic refresh. 
While there is no specific reference model supporting this activity, and general knowledge of all is 
advised. As state governments and other "consuming" entities start building and implementing their 
enterprise architectures, these provide inputs to add to and enrich the reference models. This 
feedback process (see Figure 4-4) should be formalised and internalised, in order to close the loop. 
Development of the compliance process and items are informed by all the reference models. 
Similarly, reference models should be built into a commercially available EA tool, if the government 
entities so desire to automate the administration and management of architecture activities. 

Major issues that need to addressed in these phases include: 

1. What mechanisms and processes are in place to ensure that the architecture is adopted and 
used? 

2. Which organisational activities should be using enterprise architecture? How? 

3. How do we ensure that the reference models are kept updated and fresh? What institutional 
mechanisms are in place? 

4. What portions of the architecture specifications should be made public to enrich and steer the 
procurement process? How can these be used to evaluate vendors? 

5. When and how should the architecture implementation be assessed for compliance? What are 
the action items resulting from such assessments? 

6. To what extent is tool support need to accelerate the development and use of enterprise 
architecture? What formal notations should be supported? 

7. Is there a need for an independent review of architecture capability and maturity? 

8. What steps have been taken to educate the relevant stakeholders? How are we evaluating the 
effectiveness of such activities? 

9. Have we established a metrics and measurement programme? Is this aligned to the PRM? 

10. When do we know we have done enough? What is the cycle exit / completion criteria? 

11. Is there a success criteria? Who should these be reported to - citizens, lawmakers, auditors? 

The suggested outputs from these phases include: 

• Architecture Governance Strategy (Detailed) 

• Architecture Adoption Plan 

• Architecture Management Plan 

• Implementation Specifications (RFP or Tendering Process) 

• Architecture Compliance Checklist and Process 

• Architecture Management System Implementation Report 

• Requirements Management Approach and Plan 
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ADDITIONAL PHASE: CONCEPTUAL SOLUTION ARCHITECTURE 

This is an additional phase which extends the standard ADM. From a state government 
perspective the need for this is driven by four factors: 

• Depicting the link from enterprise architecture to the downstream activity of solution 
architecture; 

• Building the capability to realise the target architecture; 

• Providing an integrated view of the services, systems and technology architectures in a visible 
way; and 

• Enabling and enriching the procurement process by getting a better understanding of constraints, 
risks, possibilities and users. 

Guided by the priorities elaborated in the target enterprise architecture and the overall 
business vision and mission, the development of the conceptual solution architecture initiates with 
the assessment of current systems and services to determine the business value and overall 
alignment to business goals and objectives. Based on the analysis of the current systems and services, 
the requirements for the target systems and services are derived in a way that conforms to the target 
enterprise architecture. In developing target solution architecture, the reusable components (from 
the various reference models) should be used. This should also include understanding the 
dependencies, constraints, risks and issues in getting the architecture components to work together 
coherently. Capabilities that are not covered in the reference models, should be defined as reusable 
components and as part of the institutional governance mechanism these can becomes candidates 
to be included in the next update of the IndEA (see Figure 4-4). To the extent possible, the outputs 
from this phase should be vendor and technology agnostic. Refer to Figure 5-4 for activity-wise 
mapping. 

Critical factors that need to be addressed in this phase include: 

1. How are systems and services in the selected area / domain / unit / function performing to deliver 
business value for costs associated in operating and maintaining them? 

2. How are the current systems and services linked? What data sources do they use? 

3. What risks are associated with existing systems and services? Do these risks affect business 
continuity? 

4. What systems and services should be retired / decommissioned? What should be retained for the 
target state? Are the reasons retention clear and understood? 

5. What security and privacy monitoring activities should be considered for the target state? 

6. What is the prefered solution development model? Is the implementation in-sourced or out¬ 
sourced? 

7. Have the target systems and services been consolidated, rationalized and combined as a portfolio 
(representing a group of similar or highly dependent systems and services)? 

8. Is the portfolio reflected in the transition roadmap? 

9. Are there reusable components identified that can potentially be included in the next cycle of the 
IndEA reference models? 
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The suggested outputs from this phase are: 

• Current Systems and Services Analysis Report 

• Current Conceptual Solution Architecture 

• Target Conceptual Solution Architecture 

• Target Service Component Architecture 

• Target Deployment Strategy and Architecture 

• Solution Transition Roadmap 

• Conceptual Solution Architecture Presentation 
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5. Mapping ADM Phase Activities to IndEA 


For ease of reference, this section maps the phase-wise activities of the TOGAF ADM to the 
use of IndEA Reference Models with the following colour-codes. 


Legend 

Broad General Reference 

Secondary Reference 

Primary Reference 

No Direct Reference 


TOGAF ADM Phases 

Phase Activities 

Performance Reference Model 

Business Reference Model 

Data Reference Model 

Application Reference Model 

Technology Reference Model 

Security Reference Model 

Integration Reference Model 

Governance Reference Model 

Preliminary Phase 

Scope the enterprise organisations impacted 









Confirm governance and support frameworks 









Define and establish enterprise architecture team and organisation 









Identify and establish enterprise architecture principles 









Tailor TOGAF, and, if any, other selected architecture frameworks 









Implement architecture tools 










Phase A: Architecture Vision 

Establish architecture project 









Identify stakeholders, concerns and business requirements 









Confirm and elaborate business goals, business drivers and constraints 









Evaluate business capabilities 









Assess readiness for business transformation 









Define scope 









Confirm and elaborate architecture principles, including business principles 









Develop architecture vision 









Define the target architecture value propositions and KPIs 









Identify business transformation risks and mitigation activities 









Develop statement of architecture work 










Phase B: Business 

Architecture 

Select reference models, viewpoints, tools 









Develop baseline business architecture description 









Develop target business architecture description 









Perform gap analysis 









Define candidate roadmap components 









Resolve impacts across the architecture landscape 









Conduct formal stakeholder review 









Finalize the business architecture 









Create architecture definition document 










Figure 5-1: Mapping of ADM Preliminary, A and B Phase Activities to IndEA Reference Models 
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Phase C-l: Data 

Architecture 

Select reference models, viewpoints and tools 









Develop baseline data architecture description 









Develop target data architecture description 









Perform gap analysis 









Define candidate roadmap components 









Resolve impacts across the architecture landscape 









Conduct formal stakeholder review 









Finalize the data architecture 









Create architecture definition document 










Phase C-2: Application 
Architecture 

Select reference models, viewpoints and tools 









Develop baseline application architecture description 









Develop target application architecture description 









Perform gap analysis 









Define candidate roadmap components 









Resolve impacts across the architecture landscape 









Conduct formal stakeholder review 









Finalize the application architecture 









Create architecture definition document 










Phase D: Technology 
Architecture 

Select reference models, viewpoints and tools 









Develop baseline technology architecture description 









Develop target technology architecture description 









Perform gap analysis 









Define candidate roadmap components 









Resolve impacts across the architecture landscape 









Conduct formal stakeholder review 









Finalize the technology architecture 









Create architecture definition document 










Figure 5-2: Mapping of ADM C and D Phase Activities to IndEA Reference Models 
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Phase G: 
Implementation 
Governance 

Confirm scope and priorities for deployment and development 









Identify deployment resources and skills 









Guide development of solutions deployment 









Perform enterprise architecture compliance reviews 









Implement business and IT operations 









Perform post implementation review and close implementation 










Phase H: Architecture 
Change Management 

Establish value realisation 









Deploy monitoring tools 









Manage risks 









Provide analysis for architecture change management 









Develop change requirements to meet performance targets 









Manage governance process 









Activate the process to implement change 










Requirements Management 

Identify / document (architecture) requirements 









Baseline requirements 









Monitor baseline requirements 









Identify changed requirements, and re-assess priorities 









Assess impact of changed requirements on ADM Phases 









Implement requirements arising from Phase H 









Update requirement repository 









Implement change in the current phase 









Assess and revise gap analysis in the previous phases 










Figure 5-3: Mapping of ADM G and H Phase Activities to IndEA Reference Models 
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Additional Phase: Conceptual 
Solution Architecture 

Collect information on existing systems and services 









Evaluate business value and performance of existing systems 









Develop current conceptual solution architecture 









Identify service and solution component reuse opportunities 









Identify target system and service components 









Define relationships between target systems and services 









Identify and analyse alternatives for transition 









Develop recommendations outlining selected alternatives 









Develop and validate target conceptual solution architecture 









Publish / disseminate target conceptual solution architecture 










Figure 5-4: Mapping of Additional Phase (Solution Architecture) to IndEA Reference Models 
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6. Getting Started and Path to Fruition 

Mere availability of the reference models is not enough for government enterprises to adopt 
enterprise architecture. Government entities have to deal with many practical on-ground issues that 
are critical to address. This section lists such issues and addresses them. It is a done in a question and 
answer format for ease of understanding and greater receptivity to follow. While some of the 
answers may appear, subjective and may require fine tuning at the time of adoption, an attempt is 
made to lead the government enterprises towards a preferred approach and direction. 

a. Frequently Asked Questions on Adoption 

I. As IndEA recommends a holistic and integrated planning and structured approach, what 
happens to the currently ongoing programmes and initiatives? 

Enterprise architecture is seldom done on a clean slate. Current ongoing programmes should 
be analysed for relevance and alignment to the organisation's mission and architecture 
conformance. Programmes that are found conforming should be kept and continued, while 
those not fulfilling the requirements either have to be reworked or discontinued in a planned 
manner, without disrupting current operations. 

II. How does IndEA help in aligning closer alignment to Digital India programme? 

In order to transform the entire ecosystem of public services through the use of information 
technology, the Government of India has launched the Digital India programme with the vision 
to transform India into a digitally empowered society and knowledge economy. Therefore, 
states and other government enterprises are strongly urged to leverage on the approach and 
methodology formalized as part of Digital India. IndEA based enterprise architecture directly 
impacts eight of the nine pillars 12 of Digital India, namely - 1, 2, 3, 4, 5, 6, 8 and 9 in different 
ways. 

III. Which departments and functions should be involved in the development and adoption? 

Ideally, enterprise architecture should be a joint effort of the planning and IT departments. In 
general, IT departments are support functions, therefore may find it challenging to enforce 
certain standards in the line departments, which have much larger budgets (therefore clout). 
The important success factor would be to set up a Council of Ministers empowered to 
implement enterprise architecture across the state and other government enterprises, the 
critical point being any entity set up or involved should have adequate authority to get things 
done. 

IV. What are some areas of likely policy level changes needed to enable enterprise architecture 
adoption? 

There are several areas where policy level changes may be necessitated to implement 
enterprise architecture. Some of these areas could be, but are not limited to: 

• Changes of business processes, requiring changes to business rules; 

• Consolidation of services, therefore impacting the departments and divisions providing 
such services; 

• Security and privacy issues; 


12 http://digitalindia.gov.in/content/programme-pillars 
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• Digitisation of documents, elimination of approvals; 

• Procurement and vendor management; 

• Data exchange and sharing of data across government enterprises; 

• Shared services and other shared infrastructure; 

• Regulatory issues pertaining to Cloud ecosystem; 

V. How long and how much effort does it take to do this? 

The two major segments, i.e. planning and design should be done in less than 12 months; 
while the implementation / execution can span 3-4 years. More than these suggested 
durations, the critical success factor is sustaining the interest, funding, and ability to make mid¬ 
course corrections in a planned manner. Given that multiple initiatives emerge out of the 
architecture, it is advisable, therefore, to have a strong programme management capability 
which is able to manage the collection of initiatives as a portfolio. The advantage of bringing in 
the portfolio approach is the ability to distribute risks, and therefore enhance the chances of 
success. 

VI. Aside from the reference models, what other help is available and where does this start? 

Please see Section 7 (References and Further Reading) of this document. 

The need and importance of enterprise architecture has to be communicated to all the 
government agency staff, in particular to the key stakeholders and decision makers. Awareness 
campaigns such as presentations, workshops and seminars should be conducted. It is 
recommended that the EA Core team and working teams find the most effective ways to create 
awareness, understanding and interest. 

VII. How can existing organisational structures be leveraged to enable enterprise architecture? 

State governments or government enterprises already have apex committees to make critical 
decisions. Attempt should be made to leverage such readily available structures, rather than 
creating new ones for enterprise architecture matters. Existing structures that are already part 
of the organisations are more likely to sustain and be effective, as the channels of 
communication and influence are already in place. The aim should be to include enterprise 
architecture as part of the TOR of the such existing structures. 

VIII. Can enterprise architecture be done for one or a few departments / functions, and then 
extended to entire enterprise? 

Yes, this is very much an approach that can be adopted should there be a need to 
demonstrate success and effectiveness of enterprise architecture on a smaller scale, before 
committing to the larger canvas. For instance, within a state, the first cycle of enterprise 
architecture could be done for a single department or a geographical entity like a city or a 
municipality. Nevertheless, the key is to eventually start and sustain a culture of holistic 
integrated planning, coupled with phased implementation to suit business direction and state 
priorities. 
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IX. If vendors insist on bringing their own proprietary approaches and methods, what is the 
mechanism to make them conform? 

The aim of developing IndEA is not to discourage vendors and service providers to innovate 
and bring best practices to state governments and other government entities. As a collection 
of reference models, the aim is to encourage and enable adoption of standards. The approach 
and the methodology to fulfill the requirements of standards is not prescribed. This gives 
vendors and service providers more than adequate elbow room to maneuver, and differentiate 
their services. The process of conformance to standards as described in the RMs should ideally 
start the procurement stage itself. IndEA is meant to be a document that is easily available and 
readily shared, so that it is used to shape the ecosystem around it. 

X. What is the role NIC in this? How can state governments tap into their expertise? 

The National Informatics Centre (NIC) is the designated nodal agency for enterprise 
architecture in the country. The proposed EA-Centre of Excellence is being set up with the aim 
to provide first level support to state governments and government entities building and 
implementation of enterprise architecture. NIC, through its functionaries at the states has the 
ability to provide on-ground support and elicit feedback and learnings from various states. At 
the time of writing, this is an area that is still fluid and the support system will continue to be 
strengthened overtime. 

XI. What is the role of SeMT and existing e-Government functions in the context of IndEA? 

The State e-Mission Teams (SeMT) would need to be upgraded in skills to build proficiency in 
enterprise architecture. Members of the SeMT have the natural advantage of having on-ground 
knowledge about the state, its governance and connect at the grassroots level. This can be of 
great benefit to enterprise architecture initiatives. Understanding of and experience in e- 
governance projects can be leveraged for capacity building, awareness and advocacy, data 
collection and validation, architecture documentation, vendor and programme management, 
procurement are some critical areas where SeMT can be directly involved. Ideally, all members 
of SeMT should be certified in TOGAF. 

XII. What is the role of academia? How can their expertise be taken advantage of? 

The academia can and should play an important role in the adoption of enterprise 
architecture. One of the key impediments that confronts the industry, both government and 
private sectors alike, is the difficulty in finding experienced enterprise architects. By 
incorporating contemporary topics like enterprise architecture into their regular post-graduate 
and executive curriculum, the academia is in an unenviable position to influence the thinking, 
create interest in the topic and over time build a critical mass of qualified architects in the 
country. The aspect where the academia is in a good position to influence is through their 
regular interactions with the industry. The academia-industry collaboration provides the ability 
to even study and document case studies and use such material to enrich the pedagogy and 
reinforce interest. The Open Group India Academic Initiative 13 aims to achieve all of the above. 


13 https://www2.opengroup.org/og5vs/cataloe/Q170 
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XIII. What can be done to provide a level playing field to small and medium businesses to participate 
in the derived implementation initiatives? 

There is a general perception in the industry that stringent requirements pertaining to 
revenue, previous experience, size, credentials greatly favour larger service providers and 
consulting firms. This, for all practical purposes, shuts out small and medium enterprises as 
they find it difficult to conform to the requirements needed to qualify for any government 
work. One of the key derivatives from enterprise architecture in the government sector is to 
use this as a lever to further the digital economy (and therefore SMEs). One practical way to 
get SMEs into the implementation projects is to mandate large services providers and 
consulting firms to collaborate with SMEs and even form consortiums (with a substantial 
portion of the overall revenue earmarked for SMEs) in the tender / RFP processes. This allows 
larger service providers and consulting firms to be the primary contractor, with a certain 
portion of the implementation given to partner SMEs, and revenue pass-through. 

b. Architecture Assurance with Maturity Model 

The path of building enterprise architecture is a long term endeavour. One of the key success 
factors in continuing on this journey is to institutionalise an evaluation mindset in order to assess 
the maturity of the enterprise architecture at regular frequency. Maturity describes the extent of 
formality and optimisation of a capability. A maturity model: 

• Defines a starting point of low maturity and a target state of high maturity; 

• Demonstrates reasonable next steps at each point of development - how to succeed one step at 
a time; 

• Educates and trains stakeholders about an area of concern; and 

• Evaluates the level of maturity in the organisation, pinpointing the need for resources and skills. 

The maturity of enterprise architecture is to be measured on two dimensions. First, is the 
maturity of the enterprise architecture itself; second, the maturity of the enterprise architecture 
programme. The two-dimensional approach is needed to ensure a coherent and comprehensive 
evaluation of enterprise architecture that contributes to business success, the very essence of 
architecture assurance. 

The aim of this guide is not to provide a detailed elaboration of EA maturity model. For the 
purposes of IndEA's primary audience (ministries, state governments and local governments) the two 
dimensions of maturity model are as follows: 

Enterprise Architecture Programme 

This dimension primarily covers the programme / function / process that is established and 
followed in order to develop and implement the enterprise architecture. The maturity stages are: 

1. Initial: The architecture programme is non-existent or ad-hoc at best. 

2. Repeatable: The architecture programme is localised, limited to slivers of activities (like projects 
or teams). 

3. Defined: The architecture programme is generalised and formalised around a set of policies, 
process, procedures and work approaches. There is some discipline established. 
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4. Managed: The architecture programme is controlled and administered using a system of metrics: 
core philosophy being (if you cannot measure it, you cannot manage it). 

5. Optimised: The enterprise is taken to be a complex adaptive system (CAS), where the aim is to 
understand the entire enterprise as a system, and transition from straight-line to closed loop 
thinking. 

Enterprise Architecture 

This dimension covers the architecture itself, i.e. product of the process. The aim is to analyse 
and design organisational systems so that strategy, structure, operating models, and skill bases fit 
together effectively and efficiently, and harness this understanding to make needed transformation. 
The maturity stages are: 

A. Fractional: An informal architecture that is fragmented and disjointed. 

B. Standardised: The overarching goal is to derive economies of scale benefits by standardising, 
usually ending up with the lowest common denominator to gain highest extent of compliance. 

C. Rationalised: The primary goal is to eliminate redundancies and overlaps in order to optimise 
operations. This leads to operational efficiencies. 

D. Connected: The primary goal is to amplify the linkages between various aspects of the enterprise 
and its architectural components. Such linkages are multi-dimensional to gain new insights and 
perspectives, by analysing behaviuors over time. 

E. Coherent: The central goal here is to understand the systemic structures from where the patterns 
emerge, and synthesise them to modify mental models, an essential ingredient to achieve 
transformation on enterprise scale and intensity. 

Figure 6-1 combines the two dimensions and respective maturity stages into a single unified 
model. The model is designed to be used to identify the maturity stage along each dimension and 
assign a composite score (e.g. B4). As is evident, this can be expanded to use the model to even assign 
a target composite score and plan a transition (e.g. moving from B2 to D4) as part of the overall 
mission. In other words, this can be used for both assessment and improvement. 
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1. There is no awareness of architecture, and 
there is virtually no formal EA program to 
speak of. 

2. Current architecture is fragmented, disjointed 
and informal providing little benefit. 

3. Architecture is accidental with anecdotal 
narratives. 

L There is scattered awareness of architecture 

and benefits that can be derived. 

2. There is no formal EA program as such, but 
there are sporadic efforts. 

3. Disparate architecture is created and 
implemented from time to time, leading to 
scanty results. 

1. Executive management is aware about the 
value of architecture. 

2. There is lack of leadership and management 
to establish and sustain a formal EA program. 

3. Some form of semi-formal architecture starts 
to take shape, but not in a way that Is 
propagated and advocated across the 
organization. 

4. Organization does spend time trying to 
understand good practices and embrace. 

1. Policies pertaining to architecture are in 
place, but not diligentiy enforced. 

2. Consolidated architecture plan with common 
attributes at the BU level exists. 

3. Architecture is formal in certain areas / 
domains (e.g. segment architecture), but not 
institutionalized. 

4. Guiding coalition of good practices pertaining 
to success outcomes are established, but not 
consistently followed. 

1. Mature architecture exists in pockets, but not 
institutionalized. The footprint of the 
architecture does not span the entire 
organization. 

2. Organization-wide policies are in established, 
but implemented in silos. 

3. Segment architectures do not collaborate and 
share Information. 

4. The need for holistic perspective to deal with 
complexity is felt but lacks momentum to act. 

1. There is sparse awareness of architecture 
which is restricted to a few business units. 

2. Certain BUs embrace initial form of 
architecture by standardizing selected 
technology areas. Such decisions are 
primarily based on ease of adoption and 
demonstrable early results. 

3. These business units operate In silos and no 
interaction with other units, therefore efforts 
and benefits are one-off / ad-hoc 

L The awareness propagates to the senior 

management of a few BUs. Establishment of a 
formal EA program is set in motion. 

2. Technology standardization gains acceptance 
in more BUs and such decisions are 
increasingly based on economies of scale 
benefits. 

3. New technology areas are added to the 
portfolio, in some cases gaining from the 
learning of previous Initiatives. 

1. The benefits of architecture as a 
standardization mechanism gain traction 
across the organization. 

2. Economies of scale benefits start to show 
results, thereby gaining deeper acceptance. 

3. Policies enabling technology standardization 
are established, though enforcing and 
governance are weak. 

4. Technology reference architectures in 
primitive form start to take hold. 

1. Technology architecture is relatively mature 
and adopted organization-wide. 

2. Technology domains are identified, prioritized 
and standards used to guide acquisition / 
procurement decisions. 

3. Policies are established consistently enforced 
organization-wide. 

4. A formal full time architecture team is 
established, though there are capability gaps. 
Federation starts to take root. 

1. Technology reference model is proactively 
reviewed and updated. The changes are 
reflected In the technology architecture. 

2. Continuous improvement is institutionalized, 
through a system of metrics. 

3. The technology architecture is mature, 
organization-wide and aligned to business 
needs. 

4. learnings are transferred and extended to 
other areas like application architecture. 

1. There Is growing awareness of architecture 
within a few business units. 

2. Certain BUs follow-up their initial efforts with 
some kind of application portfolio 
rationalization as a one-off activity. Such 
activities are within the first-mover BUs. 

3. Any architecture effort is a result of individual 
BU zeal, often being personality driven rather 
than outcome of a formal program. 

4. Results are often greeted with cynicism. 

L A few BUs start developing EA vision, though 

primitive. 

2. Efforts to rationalize applications are 
expanded to include mission critical systems. 

3. BUs start formalizing processes and 

procedures. In an effort to capture 
knowledge and avoid reinventing the wheel. 

4. Results and outcomes are now more 
palatable and attract less cynicism, leading to 
greater adoption. 

1. There is a growing realization of taking the 
architecture footprint beyond technology, 
and expand it to include business critical 
applications and systems. 

2. Application portfolio rationalization becomes 
an organization-wide activity. 

3. Interplay of benefits of technology 

standardization and application 

rationalization amplifies good results, drives 
greater adoption and institutionalization. 

1. Application architecture Is relatively mature, 
and rationalized. 

2. Common and shared application service 
capabilities are identified, though not 
adopted consistently. 

3. Key data is rationalized, and data governance 
is established, and an organization-wide data 
reference model Is put In place. 

4. Business operations are optimized, using 
architecture to accelerate. 

1. Application reference model Is proactively 
reviewed and revised. These changes are 
reflected in the application architecture. 

2. Application architecture guides all system 
development and compliance is achieved. 

3. Common service capabilities are used during 
analysis and design across the value chain. 

4. Optimal end-to-end business processes work 

efficiently, weeding out overlaps, 

redundancies and filing gaps. 

1. There is growing realization of the benefits of 
architecture, which are primarily a result of 
certain low-hanging fruits. 

2. Certain avant-garde BUs move ahead by 
understanding and linking some data across 
applications, to provide a connected 
perspective to users / consumers. 

3. Differentiation between shared and common 
data and application services is non-existent. 

4. Experience and results are not propagated. 

1. Within certain 8Us, there is significant level of 
technology standardization, applications 
rationalized and key data linked to be able to 
support end-to-end perspectives. 

2. There is primitive differentiation between 
common and shared data and applications to 
allow for better data and application 
management, with EA used for solution 
planning and design. 

3. Experience and results are propagated, within 
the BUS. 

1. Most critical BUs now have technology 
standardization, coupled with rationalized 
applications and key data linked. 

2. Business critical processes have an end-to- 
end perspective allowing for greater flexibility 
and faster decisions. 

3. Experience and results are now propagated 
through the entire organization. 

4. Executive management is convinced about 
the internalization for future success. 

1. Data architecture is relatively mature, and 
organization-wide. 

2. Agility is achieved by having traceability 
between data, application and technology 
architectures. 

3. Key business processes are digitized and 
provide transient advantage. 

4. Architecture process is supro-deportmentol 
and deliverables are operational, enabling, 
diagnostic, actionable and measurable. 

1. Data reference model is in place, used to 
steer data sharing, collaboration and 
rationalization at the organizational level. 

2. Data governance is holistic. Data is 
synchronized to business functions and 
processes, to provide full scale line-of-sight as 
an enterprise connected view. 

3. Connected view actualizes epoch-era analysis. 

4. Responsiveness is crucial to deal with 
emergence, resulting from complexity. 

1. There are clear first-movers, certain 
progressive BUs realize the full benefits of 
architecture. 

2. Operational business architectures within 
certain BUs are linked to data and application 
architectures. 

3. Efforts are still deemed experimental, with 
limited indination to scale out to other BUs, 
therefore establishing a formal EA program is 
remote. Initial results and benefits are mostly 
squandered. 

L The first-movers are able to stand-out and 

start getting noticed. There is a desired need 
to extend the influence of a formal EA 
program. Governance committees start to 

2. Business driven integrated architecture 
begins to take shape. There is a desire to 
scale out to include key BUs, and repeat 
successes. 

3. Architecture is used to drive and optimize 
project prioritization. 

1. The architecture spans the entire 
organization and improves its use of IT. 

2. The organization puts a strategy to sustain 
and accentuate a problem-based approach. 
There are specific interventions to deal with 
risk and uncertainty. 

3. The architecture supports a broader set of 
value propositions, which essentially focus on 
achieving superior business performance. 

4. Architecture is modular to support strategic 
outcomes with reactive monitoring. 

1. The architecture is an integral part of the 
strategy definition and execution process. 

2. Architecture interventions are proactively 
tracked using a system of metrics. The 
architecture team has required authority to 
enforce interventions. 

3. Enterprise as ecology and architecture is used 
to gain business insights. 

4. leadership as orchestration understands the 
value of coherency and architecting involves 
scenario planning with multiple futures. 

1. Architecture factors in ambiguity and flux. 
Metrics are used as a system of management. 

2. Architecture is the means to achieve business 
coherence - l.e. matching external 
positioning to internal capabilities and 
incorporating the temporal dimension. 

3. The organization applies the systemic 
paradigm in identifying architecture 
Interventions with cascading benefits. 

4. Visioning and foresight are architecture 
derived, and used for future capabilities. 
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